Device Identities

Document Purpose

To clearly outline the need for strong device identities; requirements and use cases.

To identify existing industry methods methods.

To outline an optimum methodology for expressing device identities and associated attributes

To help define the different methods of provisioning identities and updating attributes (factory provisioning and updates).

General Requirement

To reason about a device at a distance (over the network), we have some fundamental requirements

1. we require stable device identities over time, communicated in a secure, attestable fashion
2. we required additional device attributes, also communicated in a secure, attestable fashion

There is some potential contention between the requirement for a stable device identify, which is principally hardware based, and certain dynamic device attributes, which are more software based (MUD and SBOM being two such example )

Actuator requirement

To manage a device on a network we need to be able to identify it.

Classic network management techniques user largely ephemeral or spoofable properties e..g IP address or MAC address.

• e.g. allocating IP addresses to authorised MAC addresses
• Permisioning network access by MAC address
• Segmenting a network by IP address
• Mapping ports by IP address

If you are actively managing a network which is under attack, clearly these attributes/properties cannot be trusted

An ideal solution would allow us to actively managed a device on a network using an immutable and verifiable identity

Privacy requirement

A frequent end use requirement is to limit the non permissioned disclosure of a device identity to network listeners.

This to prevent or limit non permissioned user and device tracking

Rotating MAC addresses have been introduced to mobile phones to satisfy this requirement.

IOT requirement

• IOT devices typically have more deterministic (less volatile) network behaviour than enterprise, desktop or mobile software
• IOT devices can have their software updated, but it tends to happens less frequently than for enterprise, desktop or mobile software
• The typical granularity of software update is more coarse than alternatives. It can be typically monolithic firmware's. Ie there are few dimensions of independent software update.

Device Identity Status quo

The current dominant method of asserting device identity is defined in the IEEE specification https://1.ieee802.org/security/802-1ar/

There are additional methods, which may or may not be compatible, such as

• Matter
• FIDO
• ???

?? Where does RATS sit with this?? https://datatracker.ietf.org/wg/rats/about/

?? Where does SUIT sit with this?? https://datatracker.ietf.org/doc/rfc9124/

Secure Dynamic device attributes

To reason about the security posture of a device we additionally need to remotely communicate certain dynamic attributes, relating to the device. But this also needs to be secure and remotely attstable

Immediate examples

• MUD
• SBOM

Both of these attributes are likely to change after a software update. Detailed considerations below

Examples

MUD

The MUD defines three ways of communicating the MUD URL

• MUD URL DHCP Option
• MUD URL X.509 Extension
• MUD LLDP Extension

The DHCP option is fundamentally insecure. We need to exercise caution using/promoting this method

The X.509 method can appear in a number of certificates including IDevID

The LLDP: need to understand the security characteristics and Lifecyle characteristics

The fundamental issue that needs addressing: how do we update the MUD description following a firmware (or configuration update), but retain stability of device identifier.

SBOM

Currently the question of how does a system (whether dynamic enterprise software or static IOT device) declare to another party what's is SBOM is, is currently unsolved.

(recent DHS conversations)

There have been conversations about using MUD mechanics to communicate

Option space

Direct or indirect

The payload or attributes to be communicated (e.g. SBOM/MUD), can be done in structured JSON (or optimised binary representation)

These attribute descriptor documents could be communicate directly (peer to peer) or indirectly (via URI)

Indirectly communication would require access to internet or other lookup methods.

Ideally these documents should be signed, but the signatory must be verifiable, either directly or indirectly (using a signing chain)

Legacy

The legacy problem is a hard problem.

To encourage adoption, we should strive to a solution that can be applied to legacy use cases.

D3 was designed to address this scenario. D3 allows attributes to be defined from trusted sources but allows this "type meta data" to be loosely coupled to individual device instances, using either human or automatic recognition processes

Updates

The core device identity should only be updated infrequently.

Attribute documents can be updated more regularly

If the device is managing the attribute document - the attribute documnt should be signed by the devices private key

Discussion

Unless there are good solutions already in place, it seems very likely that device will need two strong identities

• Hardware based identify: immutable and persistent and tied to the hardware
• Software based identity: tied to some mix of firmware and configuration.

The software based identity will (probably) need to be counter sided by the hardware based identity, after a successful install.

The secure dynamic attributes (MUD/SBOM etc) will need to be signed by the software identity